Use HLM-provided land-use time series data to drive FATES harvest #663
Conversation
update my fork with master
update my fork with original
Updated fates interface to receive harvest data from hlm. This includes flags denoting whether to use hlm harvest or fates logging, and whether the hlm harvest is area or carbon. Have not implemented the actual harvest yet, and plan to use fates logging parameters to direct it. Changes to be committed: modified: biogeochem/EDLoggingMortalityMod.F90 modified: main/FatesInterfaceMod.F90
Completed the initial code for passing land use harvest from ELM to FATES. Still need to debug and test. Changes to be committed: modified: biogeochem/EDLoggingMortalityMod.F90 modified: main/FatesConstantsMod.F90 modified: main/FatesInterfaceMod.F90
Changes to be committed: modified: biogeochem/EDLoggingMortalityMod.F90 modified: biogeochem/EDMortalityFunctionsMod.F90 modified: biogeochem/EDPatchDynamicsMod.F90
Changes to be committed: modified: biogeochem/EDLoggingMortalityMod.F90 modified: main/FatesInterfaceMod.F90
The harvest data from landuse.timeseries are passed to FATES for logging. The FATES logging parameters are used to guide harvest. Only area fraction data are implemented, and these fractions are applied to the FATES logging intensity parameters. The desired effect is for the given logging intensity to be applied to a fraction of the cohort determined by the HLM harvest rate. Separate fractions are applied to primary and secondary patches. This is a working version for testing. Changes to be committed: modified: biogeochem/EDLoggingMortalityMod.F90
…/secondary area error from patch fusion
…ter all the secondary patches, and error-check if the code tries to merge patches with different labels
…xists, during logging
…ssociated disturbance
This reverts commit 3afe8ed.
…m BCs" This reverts commit 29dabcc.
Conversion to secondary land due to harvest is based on the area harvested, not just the logged crown. Also, the harvest_carbon_flux diagnostic has been updated to align with the wood_product output. Note that these are in different units and that monthly average output during harvest month is different for each. Changes to be committed: modified: biogeochem/EDLoggingMortalityMod.F90 modified: biogeochem/EDPatchDynamicsMod.F90
ckoven
requested review from
rgknox,
jenniferholm,
lawrencepj1,
huangmy,
rosiealice and
dlawrenncar
Co-authored-by: Rosie Fisher <[email protected]>
|
some note from a discussion with @rgknox on this PR: (1) right now, the CTSM code is assuming that the harvest is area-based (see here: https://github.com/ckoven/ctsm/blob/fates_landuse/src/utils/clmfates_interfaceMod.F90#L340). the problem is that right now, the way we are specifying the units happens early in the call sequence. Instead, the suggestion is to change this to make sure that the units that are read in (here: https://github.com/ckoven/ctsm/blob/fates_landuse/src/biogeochem/dynHarvestMod.F90#L124) are passed through the interface alongside the rates (also rename these as per #663 (comment)). At some later point we can update that to use a parameter interface that @rgknox has developed for the nutrient code to handle a similar problem, which should be more efficient. (2) at some point we should add some checks to ensure that parameter values make sense. in particular, the harvest timeseries code only really makes sense for certain values of the (3) a few little things, e.g. change name of |
After looking at the code more, I realize that we do calculate logging time on all threads, we only use the pointer to the main thread to filter out print statements to prevent redundant messaging. This call may be inefficient (although it is incredibly cheap compared to other operations its not worth improving) but I don't think there is anything wrong anymore. |
| @@ -55,6 +58,12 @@ module EDLoggingMortalityMod | |||
| use PRTGenericMod , only : sapw_organ, struct_organ, leaf_organ | |||
| use PRTGenericMod , only : fnrt_organ, store_organ, repro_organ | |||
| use FatesAllometryMod , only : set_root_fraction | |||
| use FatesConstantsMod , only : primaryforest, secondaryforest, secondary_age_threshold | |||
There was a problem hiding this comment.
An idea for down the road, in the US Forest Service most harvesting/logging is done with a specific age class outcome as an object. The classes are: even-age (one age class, total range of ages present <20% of the rotation age), two-aged (two age classes), and uneven-aged (three or more distinct age classes), all of which have their own harvest practices associated with them. This may be useful designation in the future as more logging/harvest features are added.
biogeochem/EDLoggingMortalityMod.F90
Outdated
| lmort_direct = 0.0_r8 | ||
| l_degrad = logging_direct_frac * adjustment | ||
| lmort_direct = 0.0_r8 | ||
| l_degrad = harvest_rate |
There was a problem hiding this comment.
Does this mean that if trees are not large enough to log, the cohort is still degraded/moved to secondary patch?
There was a problem hiding this comment.
Oh, never mind I see, background degradation rate regardless of logging.
…tches with fates_unset_r8
|
@aldivi and I have had a bunch of discussions in the past days with various stakeholders (@JoshuaRady @KatieMurenbeeld @lawrencepj1 @dlawrenncar @wwieder @ekluzek) and I think that all are okay with this PR as it currently stands, so I think it is ready to test and then merge if tests pass. |
|
Hi Charlie
Yes, I agree that PR will enable the functionality required by FATES to do
prescribed wood harvest with no impact on the non FATES wood harvest. I
also agree with Dave @david Lawrence <[email protected]> idea on using the
streams functionality long term as there will be information from the LUH2
data that is needed for FATES which has been normalized to PFT level in the
non FATES wood harvest.
Peter
--
Dr Peter Lawrence
Terrestrial Science Section
National Center for Atmospheric Research
1850 Table Mesa Drive
Boulder Colorado 80305
Work: 1-303-497-1727
Cell: 1-303-956-6932
…On Wed, Jul 8, 2020 at 10:40 AM Charlie Koven ***@***.***> wrote:
@aldivi <https://github.com/aldivi> and I have had a bunch of discussions
in the past days with various stakeholders ***@***.***
<https://github.com/JoshuaRady> @KatieMurenbeeld
<https://github.com/KatieMurenbeeld> @lawrencepj1
<https://github.com/lawrencepj1> @dlawrenncar
<https://github.com/dlawrenncar> @wwieder <https://github.com/wwieder>)
and I think that all are okay with this PR as it currently stands, so I
think it is ready to test and then merge if tests pass.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#663 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AC3OJOIJJO5VSWYRYKM6FI3R2SOPTANCNFSM4N4YGMYA>
.
|
|
Regression tests underway UPDATE: @ckoven everything looks good except that the If I'm reading the diagnostic output from the log correctly it looks like its failing on secondary forest and the |
|
noting here some diagnostics based on a global 4x5 historical tranisent run that I made in a jupyter notebook here. The notebook shows some issues that needed to be worked out on the version of the code that I used for the run, which I believe to have been corrected since, but I am also noting here that while I think this code is now ready to be merged I want to return to these diagnostics at a later date once we are using the raw LUH2 as the driver (and also have better global productivity and biomass behavior). https://github.com/ckoven/landuse_runscripts/blob/master/landuse_global_analysis.ipynb |
|
Ran regression test on update post bugfixes. All expected PASS. Only differences due to new history variables added and answer changing results for the |
Fates harvest offmaster deconflict
These changes provide a first version of land use change, as driven by the CLM & ELM landuse.timeseries files that currently drive the big-leaf versions of the models, and should allow global transient simulations with land use.
The idea is that the HLMs read a series of land-use driving datasets (as they already do), which they'll now then pass through the HLM-FATES interface via the interface variable
bc_in%hlm_harvest(num_lu_harvest_cats). Currently the default is that the HLM reads and passes five area-based logging streams, for harvest from various categories of land (primary forest, primary nonforest, secondary young forest, secondary young nonforest, secondary old forest). FATES uses this data to harvest from three separate types: primary lands, secondary young lands, and secondary old lands. FATES does not distinguish between forest and no-forest lands, though possibly a future step could be to infer that either from the composition of a given patch or as specified if prescribed biogeography is turned on. Mass-based harvest and associated disturbance is not yet implemented here, that is also a next step.The harvest parameters are kept from before, though their usage and meaning are slightly different.
The event code triggers when within the year to apply the harvest rates, the direct_frac determines what fraction of trees within the harvested area are removed (so
fates_logging_direct_frac=1means clearcut), etc. Plants within the logged area that are not harvested, whether because they are not trees, are not within the dbhmin threshold, or because(fates_logging_direct_frac + fates_logging_mechanical_frac + fates_logging_collateral_frac ) < 1are all moved to a newly-disturbed secondary patch, along with an equivalent fraction of bare ground of each harvested patch if the canopy is not closed. So the definition of secondary lands includes everything from full clearcut disturbance to potentially relatively low-intensity forest degradation. But for consistency with the intention of the land-use datasets, we should probably set the default values to be closer to clear-cut type of conditions. Future steps may include making these arguments harvest-type-dependent. Also we still need to wire themax_dbhparameter introduced in #659 to this logic, once that code is merged into this.We added a bunch of diagnostics to serve as either sanity checks or other trackers of things that might be useful, including tracking various disturbance rates, as well as 'potential disturbace' rates (i.e. the disturbance rates before the part of the code where it says only resolve a given patch's most dominant disturbance type on a given day). Also changed the newly-disturbed patch insertion to fix a bug as described in #660.
This isn't really ready to be merged just yet, in particular the merging with the prescribed biogeography (#632 and follow-on) will most likely be a bit tricky. But putting up for interested parties to start reviewing.
fixes: #660, #491, #276, and the first batch of changes described in #450.
Collaborators:
co-written by @aldivi and me. @aldivi also wrote the E3SM-side changes of these (PR to come later) and I wrote the CTSM-side changes (PR ESCOMP/CTSM#1040).
Expectation of Answer Changes:
This should only change answers when logging is operational. But this hasn't been formally tested yet and probably requires some new tests that use the land-use timeseries data.
Checklist:
Test Results:
CTSM (or) E3SM (specify which) test hash-tag:
CTSM (or) E3SM (specify which) baseline hash-tag:
FATES baseline hash-tag:
Test Output: